1. Field of the Invention
The present invention relates to an e-mail transfer method and device, and in particular to an e-mail transfer method and device for transferring an e-mail by a public key cryptography between an e-mail transmission device and an e-mail reception device.
2. Description of the Related Art
As prior art methods of encoding plaintext of an e-mail on the Internet, a common key cryptography using a key common to encoding (also referred to as encrypting) and decoding (also referred to as decrypting) and a public key cryptography using keys different from each other for encoding and decoding have been known. Plaintext in this description indicates an e-mail message before being encoded.
In the above-mentioned common key cryptography, an e-mail transmission device (hereinafter, occasionally referred to as mail transmitting user or client) and an e-mail reception device (hereinafter, occasionally referred to as mail receiving user or client) preliminarily possess a common key, the mail transmitting user transmits to the mail receiving user encoded text (also referred to as ciphertext) that is plaintext encoded with the common key, and the mail receiving user decodes the encoded text with the common key. Thus, “information leakage” in the transmission process from the mail transmitting user to the mail receiving user can be prevented. However, it is difficult to place an e-signature for preventing an unauthorized third person from “pretending” (also referred to as “spoofing”) and “manipulating” (also referred to as “falsification”), so that a safe distribution of the common key is required.
In order to counter the above-mentioned problem, the public key cryptography prepares a pair of different keys, so that the different keys are used for encoding and decoding respectively. One is made a public key released to a transmitting destination, and the other is made a private key (also referred to as a secret key) stored only by the transmitting side itself at hand. Encoded text (ciphertext) encoded with the public key can be decoded only with the private key which is one of the pair, and the encoded text encoded with the private key can be decoded only with the public key which is one of the pair. Also, as for the above-mentioned public key and the private key, it is mathematically difficult and actually impossible to prepare one key from the information of the other key.
Upon transmitting an encoded e-mail e.g. by the public key cryptography to the mail receiving user, the mail transmitting user encodes plaintext with the public key of the mail receiving user into the encoded text to be transmitted to the mail receiving user. The mail receiving user having received the e-mail can obtain the original plaintext by decoding the encoded text with its own private key. Therefore, even if an unauthorized third party taps the e-mail in the transmission process of the e-mail, the plaintext can not be obtained unless he/she has the private key for decoding. Accordingly, the leakage of the e-mail message to the unauthorized third party can be prevented.
Also, upon transmitting to the mail receiving user a mail e-signed by the public key cryptography, the mail transmitting user prepares a hash value (hereinafter, referred to as digest) by applying the plaintext to a certain hash function, and encodes the digest with the private key of the mail transmitting user to make an e-signature which is added to the plaintext, so that the e-mail is transmitted to the mail receiving user. The mail receiving user having received the mail with the e-signature decodes the e-signature with the public key of the mail transmitting user, and confirms whether or not the e-signature is coincident with the digest prepared from the plaintext independently.
It is to be noted that there is a possibility that the same digest can be obtained from two plaintexts logically different from each other when the digest is prepared from the plaintext as mentioned above. However, a probability of getting the same digest coincidentally from two plaintexts is actually extremely low. Also, it is impossible to prepare plaintext from a certain digest. Also, which can prepare the digest which can be decoded with the public key of the mail transmitting user is only the private key of the mail transmitting user.
Accordingly, when the comparison result of the above-mentioned digests provides a coincidence, the mail receiving user having received the e-mail recognizes that the e-mail is not transmitted by an unauthorized third party but is transmitted by the mail transmitting user undoubtedly, and further the contents are not manipulated in the process of the mail transmission.
Therefore, in the encoded and e-signed mail (hereinafter, occasionally referred to as “encoded/e-signed”) by the public key cryptography, a threat on security (“pretending”, “information leakage”, “manipulation”) is prevented. The e-mail can be safely transmitted/received to/from the opponent communicating device.
The procedure of transmitting/receiving the encoded/e-signed mail by the public key cryptography will now be described in detail referring to FIG. 19 (Internet security text <vol. 1>; publisher: IDG Japan; see page 217 of ISBN:4872804759).
When a client (mail transmitting user) 91A transmits an encoded/e-signed mail to a client (mail receiving user) 91B, the mail transmitting user 91A prepares a digest (message digest) 92c by applying plaintext 92a to a message/digest function 92b (at step S91). The mail transmitting user 91A encodes the digest 92c with its own private key 91β to obtain an e-signature 92d (at step S92).
The mail transmitting user 91A further encodes the plaintext (message) 92a and the e-signature 92d with a common key 91ε to prepare encoded text 92e (at step S93), and encodes the common key 91ε with a public key 91γ of the mail receiving user 91B to prepare a common key 91 ζ (at step S94).
The mail transmitting user 91A adds the common key 91 ζ to the encoded text 92e to prepare an e-mail 92g (at step S95) to be transmitted to the mail receiving user 91B.
On the other hand, the mail receiving user 91B having received the e-mail 92g decodes the encoded common key 91 ζ into the common key 91ε with its own private key 91δ (at step S96), and decodes the encoded text 92e into the plaintext 92a and the e-signature 92d with the common key 91ε (at step S97).
The mail receiving user 91B applies the plaintext 92a to the above-mentioned message/digest function 92b to prepare a digest 92c1 (at step S98), decodes the e-signature 92d into a digest 92c2 with the public key 91α of the mail transmitting user 91A (at step S99), and verifies whether or not the digest 92c1 is the same as the decoded digest 92c2 by comparing both digests (at step S100).
It is to be noted that in the above-mentioned description, the mail transmitting user 91A does not directly encode the plaintext 92a with the public key 91γ of the mail receiving user 91B, but prepares the temporary common key 91ε for transmitting the e-mail, encodes the plaintext with the common key 91ε, and includes the common key 91ε encoded with the public key of the mail receiving user 91B in the e-mail to be transmitted to the mail receiving user 91B.
In the encoding/decoding by the public key cryptography, processing load is heavier compared with that by the common key cryptography, and requires much time. Therefore, the entire long plaintext is not encoded by the public key cryptography, but the above-mentioned common key 91ε is encoded with the public key 91γ of the mail receiving user 91B, so that speed enhancement of processing is achieved. It is not different from the encoding with the public key 91γ of the mail receiving user 91B substantially.
It is to be noted that the above-mentioned encoded/e-signed mail is prepared by combining the encoding of the plaintext with an addition of an e-signature, e.g. by encoding the plaintext to which the e-signature is added. Accordingly, the encoded e-mail or the e-signed mail can be prepared as a sub-set of the encoded/e-signed mail.
In order to prepare the encoded/e-signed mail by the public key cryptography, the mail transmitting/receiving user is required to preliminarily obtain the public key of the opponent user and to confirm authenticity of the public key obtained and its owner.
However, anyone can prepare a pair of public key and private key, wherein there is a possibility that an unauthorized third party pretends to be an authorized mail transmitting/receiving user to release the public key. In order to counter this, a certification authority becomes necessary which manages a public key used in an electronic commerce or the like on a neutral ground as a reliable third party organization, which issues a certificate in which a signature of the certification authority itself is added to a requested public key, and which guarantees the authenticity of the public key and its owner.
Thus, it becomes possible for the mail transmitting/receiving user to register the public key and to have the certification authority issue the public key certificate in which the public key and various attributes such as names, belonging organizations and e-mail addresses are described. By the public key certificate issued from the certification authority, the mail transmitting/receiving user can confirm the authenticated public key and public key certificate of the opponent user.
It is to be noted that the entire infrastructure including the certification authority, the public key encoding technology, the public key certificate, the functions realized thereby, etc. is called PKI (Public Key Infrastructure).
As mentioned above, in order to transmit/receive the encoded/e-signed mail, the mail transmitting/receiving user is required to preliminarily acquire its own public key certificate from the certification authority and to acquire the public key certificate of the opponent user.
When the encoded/e-signed mail is transmitted/received, the mail transmitting/receiving user is required to use its own private key and the public key of the opponent user.
It is to be noted that when the mail transmitting/receiving user transmits/receives the encoded mail, the mail receiving user preliminarily acquires the public key certificate from the certification authority, and the mail transmitting user has only to acquire the public key certificate. Also, when the mail transmitting/receiving user transmits/receives the e-signed mail, the mail transmitting user preliminarily acquires the public key certificate from the certification authority and the mail receiving user has only to acquire the public key certificate.
Such a certification authority, a public key certificate and a certificate revocation list will now be specifically described referring to FIGS. 20, 21A and 21B.
FIG. 20 shows a process in which a certification authority (CA) 93 issues a public key certificate, and the mail transmitting/receiving user transmits/receives an encoded/e-signed mail. FIGS. 21A and 21B show a format 97F of a public key certificate and a format 99F of a certificate revocation list. These are formats (X.509 Version 3) prescribed by the ITU (International Telecommunications Union) and are generally and frequently used. It is to be noted that the certificate revocation list will be described later.
In FIG. 20, the certification authority 93 issues a public key certificate 97 at the request of a person or an organization (client 91C) receiving the issue of the public key certificate 97. The certification authority 93 has a server (referred to as repository) 94 for releasing the public key certificate 97. The certification authority 93 and a certification authority 95 have a relationship of mutual authentication. When the person or the organization having the certification authority 93 issue the public key certificate 97 files an application of the issue (at step S101), the certification authority 93 issues the public key certificate 97 according to the application (at step S102).
The certification authority 93 releases the public key certificate 97 issued by a repository 94 to an indefinite number of persons (at step S103).
Thus, when the public key certificate 97 is issued to the mail transmitting user (client) 91A and the mail receiving user (client) 91B respectively from the certification authority 93, the mail transmitting user 91A and the mail receiving user 91B respectively acquire the public key 91γ and the public key 91α of the opponent user. For example, the mail transmitting user 91A retrieves the repository 94 with the user name of the mail receiving user 91B to acquire the public key 91γ (at step S105), or acquires the public key 91γ from the mail receiving user 91B (see arrow Y). Similarly, the mail receiving user 91B retrieves the repository 94 with the user name of the mail transmitting user 91A to acquire the public key 91α (at step S106) or acquires the public key 91α from the mail transmitting user 91A (see arrow X).
When each of the mail transmitting/receiving users 91A and 91B respectively obtains the public key of the opponent user, the mail transmitting user 91A can transmit an encoded and e-signed e-mail to the mail receiving user 91B by the public key cryptography.
It is to be noted that the certification authority 93 accepts the application of the public key certificate 97 by electronic means, by postal mails or by applicant's visit, as required according to the level of the trust (reliance or confidence) of the public key certificate 97, and also requires attachment of another certificate such as a residence certificate, a copy of register, and a certificate of seal.
When the public key certificate 97 is used in e.g. an electronic commerce or the like between enterprises with giving/receiving a great amount of money, the public key certificate 97 with higher level of trust is required.
The certification authority 93 examines the application of the applicant, issues the public key certificate 97 according to its level, and manages the issued public key certificate 97.
Also, the certification authority 93 releases the issued public key certificate 97 to an indefinite number of persons at the repository 94 and also releases a certificate revocation list and a root certificate (described later). It is to be noted that an LDAP (Lightweight Directory Access Protocol) in FIG. 20 is generally a protocol most frequently used for accessing the repository 94.
Also, when the certification authority 93 and the certification authority 95 have a relationship of mutual authentication, the transmitting/receiving user having registered the public key certificate 97 in a single certification authority 93 can transmit/receive the encoded/e-signed mail between the certification authorities 93 and 95.
The functions of the certification authority 93 are as follows:
Definition of Function in Certification Authority
    (1) Acceptance of public key certificate application
According to the level of the trust of the certificate, the application is accepted by electronic means, by postal mails or by applicant's visit, with the attachment of another certificate such as a residence certificate, a copy of register, and a certificate of seal.
Examination function according to the level of the trust of the certificate.    (2) Issue of public key certificate    (3) Management of public key certificate    (4) Release of public key certificate
Management (LDAP) of repository (server releasing required information (certificate, CRL and root certificate) concerning PKI) 94.
Release of the public key certificate 97 and release of a certificate revocation list 99.    (5) Acceptance of public key certificate revocation
A method of notifying that the public key certificate 97 becomes invalid (theft, trust decrease of object user, etc.), different from a period of validity 97b described in the public key certificate 97 (certificate revocation list; CRL).    (6) Mutual authentication with other certification authority 93
Certification authorities 93 and 95 have a relationship of mutual authentication.
Hereinafter, the public key certificate 97 will be described in detail.
In FIG. 21A, the public key certificate format 97F is provided with fields from a version 971 to an encoded text 987. Since the certification authority 93 adds an e-signature to a last signature 97d of the public key certificate 97, an unauthorized third party can not “pretend” and “manipulate”. The e-signature of the certification authority 93 is made by applying a field value from the version 971 to an extension 984 of the public key certificate 97 to a hash function 101, and by encoding the result with a private key 93 κ of the certification authority 93 to be made encoded text 102.
The certification authority 93 issues the public key certificate 97 to which the e-signature 97d is added to the mail transmitting/receiving users 91A and 91B.
When acquiring the public key certificate 97 from the certification authority 93 or the opponent user, the mail transmitting/receiving users 91A and 91B are required to verify whether or not the e-signature added to the acquired public key certificate 97 of the opponent user is authenticated. Therefore, the mail transmitting/receiving users 91A and 91B are required to preliminarily acquire “public key certificate of the certification authority itself” (hereinafter, referred to as a root certificate).
As for the root certificate preliminarily acquired, it is required to visually verify (verify the signature in FIG. 20) e.g. a coincidence of its finger print (thumbmark; numerical value of a short fixed length obtained by passing the certificate through the hash function) and a finger print released on a Web site or the like. When the above-mentioned two finger prints are coincident with each other, the mail transmitting/receiving users 91A and 91B can trust the root certificate.
Also, since the root certificate of the famous certification authority 93 is bundled with software (mail client software or the like), the mail transmitting/receiving user is not required to take the trouble to obtain the root certificate separately.
Hereinafter, the certificate revocation list 99 will be described in detail.
The certificate revocation list 99 is for informing the public of the invalidity of the public key certificate 97 when it becomes invalid for some reason (e.g. theft, trust decrease of object user, etc.) outside the period of validity described in the public key certificate 97.
In FIG. 21B, the certificate revocation list format 99F is provided with fields from an algorithm 991 to an encoded text 1000. In the same way as the public key certificate format 97F, the e-signature of the certification authority 93 is added to the last of the format 99F.
In the certificate revocation list 99, a list of a serial No. 996 of the invalid certificate is described.
Each field of the public key certificate 97 and the certificate revocation list 99 shown in FIGS. 21A and 21B will now be described in detail.
X.509 Ver3 Public Key Certificate 97
    (1) Version 971    (2) Certificate Serial Number 972
This is a unique integer value per issue certification authority 93 and corresponds to a certificate in a one-to-one relationship.    (3) Signature algorithm identifier 97a 
This includes an identifier of an algorithm 973 of a signature 97d of the certification authority 93 added to the last of this public key certificate 97 and a parameter 974 concerning the algorithm 973. These are respectively same values as an algorithm 985 and a parameter 986 within the signature field 97d described later.    (4) Issuer name 975
This is a name (X.500 name) of the certification authority 93 which has prepared the public key certificate 97 and has signed. X.500 name is a name for uniquely identifying an object on a X.500 directory which is a database with a tree structure. For example, {C=jp, O=organization name, CN=name of certification authority 93}, where C: country/O: organization/CN: Common Name.    (5) Period of validity 97b 
This includes a beginning and ending of a period of validity in the public key certificate 97.    (6) Subject name 978
This is an X.500 name of a user. For example, {C=jp, O=organization name, CN=user name, E=e-mail address of user}, where E indicates an E-mail address.    (7) Subject's public-key information 97c 
This includes a public key 981 of a user, an identifier of an algorithm 979 decoded with the key 981, and its concerning parameter 980.    (8) Issuer Unique Identifier 982
This is used for uniquely identifying the issuing certification authority 93 when the same X.500 name is reused for a different organization. This identifier is rarely used.    (9) Subject Unique Identifier 983
When the X.500 name is reused for a different user, the identifier 983 is used for uniquely identifying the user. This identifier is rarely used.    (10) Extension 984
This is a various extension field.    (1) Signature 97d 
This is a signature by the certification authority 93 of the public key certificate 97. The identifier of the algorithm 985 of the signature and its concerning parameter 986 have the same values as those in the above-mentioned signature algorithm identifier 97a. 
Certificate Revocation List 99
    (1) Signature algorithm identifier 99a 
This includes an identifier of an algorithm 991 of a signature 99c of the certification authority 93 added to the last of the certificate revocation list 99 and its concerning parameter 992. These are respectively the same values as an algorithm 998 and a parameter 999 within a field of the signature 99c described later.    (2) Issuer name 993
This is a name of the certification authority 93 which has prepared and signed the certificate revocation list 99 (X.500 name).    (3) Dates of update 994 and 995
The date of update 994 is an issue date and time of the certificate revocation list 99. The date of update 995 is a date when the issue of the next certificate revocation list 99 is expected.    (4) Invalidated signature 99b 
This includes a serial No. 996 of the invalidated public key certificate 97 and a date of an invalidation 997. By the serial No. 996, the public key certificate 97 can be uniquely identified.    (5) Signature 99c 
This is a signature 99c by the certification authority 93 of the certificate revocation list 99. The identifier of the algorithm 998 of the signature 99c and its concerning parameter 999 have the same values as those in the above-mentioned signature algorithm identifier 99a. 
Meanwhile, there is an authentication delegating method in which an authentication delegating server distributes an encoding public key of a service provider corresponding to a desired service to a client upon rendering services, and transfers encoded information received from the client to the provider, the client encodes information to be transmitted to the provider with the encoding public key received from the authentication delegating server, and transmits the encoded information to the authentication delegating server, and the provider decodes the encoded information received from the authentication delegating server with an encoding secret key (see e.g. patent document 1).
[Patent Document 1] Japanese Patent Publication laid-open No. 2001-134534
However, in the case of the prior art shown in FIG. 20, where mail transmitting/receiving users (hereinafter, occasionally referred to as simply users) 91A and 91B of an ISP (Internet service provider) freely transmit/receive encoded and e-signed mails to acquaintances even though a PKI is utilized for an electronic commerce or the like between enterprises, there are the following problems:
Firstly, since the users 91A and 91B having already joined the ISP require the public key certificate 97 of the certification authority 93, both of the users 91A and 91B require an operational effort and an issue fee according to the level of the trust of the public key certificate 97. Accordingly, even if the users 91A and 91B desire to transmit the encoded/e-signed mail for their convenience, it is required to have the opponent users 91A and 91B bear the issue cost of the public key certificate 97 of the certification authority 93 or the like.
Secondly, since the certification authority 93 manages the public key certificate 97, a management cost of the public key certificate 97 is required. Namely, the certification authority 93 releases the public key certificate 97 to the repository 94, and renders a retrieval service to an arbitrary person, so that the costs for the management and the retrieval service of the public key certificate 97 occur in the certification authority 93. Accordingly, the certification authority 93 charges the users 91A and 91B with the fees.
Thirdly, the users 91A and 91B of the ISP have a risk for distributing private information to numerous places. When the users 91A and 91B register the public key in the certification authority 93, the public key is released to an indefinite number of persons. Therefore, there is a tendency of hesitating to entrust private information to another organization different from the ISP for fear of leakage of the private information.
Also, the PKI has the following problems concerning a certificate revocation:
Firstly, although the certification authority 93 revokes the concerned public key certificate 97 by the certificate revocation list 99 released based on the statement of the users 91A and 91B, it is not guaranteed that the certificate revocation list 99 is always reflected in real time in the users 91A and 91B having already acquired the public key.
Secondly, contrary to the above-mentioned description, since the certificate revocation list 99 is widely released to an indefinite number of users, there is a problem concerning privacy that the erosion of trust of the users 91A and 91B is released to others (not a user having already acquired the public key) having nothing to do with themselves.
The above-mentioned problem of the certificate revocation occurs since the certification authority 93 can not manage to whom the users 91A and 91B should release the public key certificate 97, or who has acquired the public key certificate 97, even if the certification authority 93 manages the public key certificate 97. As for the reason why the certification authority 93 can not perform such a management, problems on a management cost or a technology (including the absence of standardization) can be conceived.
The ISP (Internet Service Provider) provides a connection environment to the Internet for the users 91A and 91B, and provides e-mail service and a mailbox for temporarily storing the e-mails. In a process of a service subscribing procedure of the users 91A and 91B, the addresses of the users 91A and 91B are confirmed by mail, or credit information of the users 91A and 91B is confirmed by credit card numbers. Also, in the above process, the ISP transmits passwords for the users 91A and 91B to connect to the network, and passwords to connect to a mail server providing the mailbox.
User authentication of the ISP indicates an authentication mechanism utilizing a user ID and a password issued by the ISP based on the confirmed private information of the user mentioned above.
The above-mentioned user authentication of the ISP has been performed by a server of the ISP with user authentication data (user ID and password) when the users 91A and 91B of the ISP transmit/receive e-mails through the Internet, and has been widely available.